Description

Currently, there are three ways to render a component:

1. HTML-like syntax
2. {% component %} tag
3. component() function

Each approach has its own limitations:

• The component() function supports dynamic component names, but does not allow blocks.
• The {% component %} tag supports blocks, but does not allow dynamic component names.
• The HTML-like syntax behaves similarly to the {% component %} tag.

Proposal

Add support for dynamic component names in the {% component %} tag.

This would enable a unified syntax that supports both:

• dynamic component resolution
• block usage

The HTML-like syntax is intentionally left unchanged, as introducing dynamic names there would result in awkward and hard-to-read syntax.

Example Usage

{% set componentName = 'MyComponent' %}
{% component componentName %}
{% endcomponent %}

Extended Idea

Allow passing a component instance directly, instead of its name:

{% component myComponent %}
{% endcomponent %}

Where myComponent is an object of a class marked with:

#[AsTwigComponent]

or

#[AsLiveComponent]

Real-world Use Case

This proposal was inspired by a real scenario in my project:

{% for tab in this.tabs %}
    {% component tab with {loading: 'lazy'} %}
        {% block loadingContent %}
            <div class="d-flex align-items-center w-75 mx-auto">
                <strong role="status">Loading...</strong>
                <div class="spinner-border ms-auto" aria-hidden="true"></div>
            </div>
        {% endblock %}
    {% endcomponent %}
{% endfor %}

In this case, tab is dynamic, and there is a need to:

• pass props (loading)
• define custom blocks (loadingContent)

Currently, this is not achievable with existing syntax without compromises.

Benefits

• Eliminates inconsistency between rendering methods
• Enables more flexible and expressive templates
• Improves DX when working with dynamic UI structures (e.g. tabs, registries, dynamic components)

Notes

• No changes proposed for HTML-like syntax
• Backward compatibility is preserved